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METHOD, SYSTEM AND PROGRAM PRODUCT FOR ELECTRONICALLY 
EXECUTING CONTRACTS WITHIN A SECURE COMPUTER INFRASTRUCTURE 

FIELD OF THE INVENTION 
[0001] The present invention generally relates to a method, system and program product for 
electronically executing contracts within a secure computer infrastructure. Specifically, the 
present invention provides an improved process for electronically executing contracts within a 
secured environment. 

BACKGROUND OF THE INVENTION 
[0002] As use of computer networks becomes more pervasive, there is a growing need to provide 
for the electronic execution/signature of contracts. Electronic execution of contracts can be both 
more efficient and cost effective than the traditional paper-based approach. One specific type of 
contract that is amenable to electronic execution is a service agreement (e.g., ServicePac). For 
example, in purchasing computer hardware, a purchaser may also desire to purchase an 
associated service agreement. As is well known, these agreements often range over a period of 
years and can have various pricing schedules. 

[0003] Unfortunately, many concerns have been raised over electronic contract execution." One 
such concern is ensuring that electronically executed contracts are legally binding as intended. 
This can be difficult unless it can be ensured a third party has not fraudulently executed a 
contract using another party's identity. 
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[0004] One technology widely implemented today is "click and accept" agreements, whereby a 
computer user is presented with a license agreement or the like on their local machine, and asked 
simply to click a button if he/she accepts the terms. Although convenient for software licenses, 
click and accept agreements are grossly inadequate for many higher stakes contracts where 
further performance is provided, for a long term relationship spanning many years, or where 
potential liability for the parties is high. For example, with a click and accept agreement, it is 
usually not necessary to specifically identify the accepting/receiving party. As such, no formal 
execution (electronic or otherwise) is performed. To this extent, the acceptance or rejection is 
performed entirely on the receiving party's computer device without subsequent communication 
with the originating party. Moreover, since a click and accept agreement must be accepted or 
rejected "as is," there is no process for a receiving party to request changes or modifications to 
the agreement. 

[0005] Another technology currently being utilized allows small value contracts (e.g., usually 
under $100.00) to be electronically executed by both parties via a public web site. Unfortunately, 
with this current technology, many important safeguards are not provided. For example, since 
the web site is public, not only is security and confidentiality lacking, but there is also no 
authentication process. Accordingly, there is no way to ensure that someone electronically 
executing the contract is actually the party named in the agreement. Moreover, the current 
technology fails to provide separate deliberate actions on the part of the parties to first approve 
and then to execute the contract. Providing each party with an opportunity to deliberately 
indicate their approval of the contract before execution would not only help to provide fairness 
for both parties, but would also make subsequent repudiation of the contract more difficult. 
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[0006] In view of the foregoing, there exists a need for a method, system and program product 
for electronically executing contracts within a secure computer infrastructure. Specifically a 
need exists for a more secure system for electronically executing contracts so that certain core 
principles, such as authentication of the parties, can be provided. A further need exists for 
approval and execution of a contract to require separate deliberate actions by the parties. 



SUMMARY OF THE INVENTION 
[0007] In general, the present invention provides a method, system and program product for 
electronically executing a contract within a secure computer infrastructure. Specifically, under 
the present invention, a customized contract is created based on the needs of the parties. Once 
created, the contract is stored within the secure computer infrastructure. Security within the 
computer infrastructure is typically provided through encryption such as 128 bit encryption. 
Moreover, all actions taken with respect to the contract (e.g., approval, execution, etc.) occur 
within the infrastructure and are recorded based on time and date so that a record can be 
provided. Still yet, any party attempting to access the infrastructure to take action will first be 
authenticated before such access is granted. In order for the contract to be electronically 
executed, both the originating contract partner and the receiving contract partner must first 
deliberately approve the contract. Once approval has been obtained, the contract can be 
electronically executed by both parties. After execution is complete, a final image of the contract 
can be generated that includes the electronic signatures and the date of execution. The present 
invention provides several key advantages over previous systems such as: security; 
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confidentiality; data integrity; data retention; data access; authentication and repudiation 
prevention. 

[0008] A first aspect of the present invention provides a method for electronically executing 
contracts within a secure computer infrastructure, comprising: obtaining contract information 
from a receiving contract partner; creating a contract within the secure computer infrastructure 
based on the contract information; requesting approval of the contract within the secure computer 
infrastructure from an originating contract partner and the receiving contract partner; requesting 
execution of the contract within the secure computer infrastructure from the receiving contract 
partner and the originating contract partner after the contract is approved by the originating 
contract partner and the receiving contract partner; and generating a final image of the contract 
within the secure computer infrastructure after the contract is executed by the receiving contract 
partner and the originating contract partner. 

[0009] A second aspect of the present invention provides a system for electronically executing 
contracts within a secure computer infrastructure, comprising: a contract creation system for 
creating a contract within the secure computer infrastructure based on contract information 
obtained from a receiving contract partner; a contract approval system for requesting and 
receiving approval determinations for the contract within the secure computer infrastructure from 
an originating contract partner and the receiving contract partner; a contract execution system for 
requesting and receiving execution determinations for the contract within the secure computer 
infrastructure from the receiving contract partner and the originating contract partner after the 
contract is approved by the originating contract partner and the receiving contract partner; and an 
image generation system for generating a final image of the contract within the secure computer 
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infrastructure after the contract is executed by the receiving contract partner and the originating 
contract partner. 

[0010] A third aspect of the present invention provides a program product stored on a recordable 
medium for electronically executing contracts within a secure computer infrastructure, which 
when executed, comprises: program code for creating a contract within the secure computer 
infrastructure based on contract information obtained from a receiving contract partner; 
program code for requesting and receiving approval determinations for the contract within the 
secure computer infrastructure from an originating contract partner and the receiving contract 
partner; program code for requesting and receiving execution determinations for the contract 
within the secure computer infrastructure from the receiving contract partner and the originating 
contract partner after the contract is approved by the originating contract partner and the 
receiving contract partner; and program code for generating a final image of the contract within 
the secure computer infrastructure after the contract is executed by the receiving contract partner 
and the originating contract partner. 

[001 1] Therefore, the present invention provides a method, system and program product for 
electronically executing a contract within a secure computer infrastructure. 



BRIEF DESCRIPTION OF THE DRAWINGS 
[0012] These and other features of this invention will be more readily understood from the 
following detailed description of the various aspects of the invention taken in conjunction with 
the accompanying drawings in which: 
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[0013] Fig. 1 depicts an illustrative system for electronically executing contracts within a secure 
computer infrastructure according to the present invention. 
[0014] Fig. 2 depicts the contract system of Fig. 1 in greater detail. 

[0015] Fig. 3 depicts an illustrative interface page containing profile information according to the 
present invention. 

[0016] Fig. 4 depicts an illustrative interface page showing a first status of a contract according 
to the present invention. 

[0017] Fig. 5 depicts an approval notice for an originating contract partner according to the 
present invention. 

[0018] Fig. 6 depicts an illustrative login page displayed upon selection of a link in the approval 
notice of Fig. 5 according to the present invention. 

[0019] Fig. 7 depicts an illustrative interface page for the originating contract partner to approve 
the contract according to the present invention. 

[0020] Fig. 8 depicts an illustrative interface page showing a second status of the contract 
according to the present invention. 

[0021] Fig. 9 depicts an illustrative approval message for a receiving contract partner according 
to the present invention. 

[0022] Fig. 10 depicts an illustrative login page displayed upon selection of a link in the approval 
notice of Fig. 9 according to the present invention. 

[0023] Fig. 1 1 depicts an illustrative interface page for the receiving contract partner to approve 
the contract according to the present invention. 
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[0024] Fig. 12 depicts an illustrative interface page showing a third status of the contract 
according to the present invention. 

[0025] Fig. 13 depicts an illustrative execution message for a receiving contract partner 
according to the present invention. 

[0026] Fig. 14 depicts an illustrative interface page for the receiving contract partner to execute 
the contract according to the present invention. 

[0027] Fig. 15 depicts an illustrative interface page showing a fourth status of the contract 
according to the present invention. 

[0028] Fig. 16 depicts an illustrative execution message for an originating contract partner 
according to the present invention. 

[0029] Fig. 17 depicts an illustrative interface page for the originating contract partner to execute 
the contract according to the present invention. 

[0030] Fig. 18 depicts an illustrative interface page showing a fifth status of the contract 
according to the present invention. 

[0031] Fig. 19 depicts an illustrative interface page for an image of the executed contract to be 
generated according to the present invention. 

[0032] Fig. 20 depicts an illustrative final image of the contract, according to the present 
invention. 

[0033] Fig. 21 depicts an illustrative interface page showing a sixth status of the contract 
according to the present invention. 

[0034] Fig. 22 depicts an illustrative interface page for viewing contract details according to the 
present invention. 
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[0035] It is noted that the drawings of the invention are not necessarily to scale. The drawings 
are merely schematic representations, not intended to portray specific parameters of the 
invention. The drawings are intended to depict only typical embodiments of the invention, and 
therefore should not be considered as limiting the scope of the invention. In the drawings, like 
numbering represents like elements. 

BEST MODE FOR CARRYING OUT THE INVENTION 
[0036] For convenience purposes, the Best Mode for Carrying Out the Invention will have the 
following sections 

I. GENERAL DESCRIPTION 

II. DETAILED EXAMPLE 

I. GENERAL DESCRIPTION 

[0037] As indicated above, the present invention provides a method, system and program 
product for electronically executing a contract within a secure computer infrastructure. 
Specifically, under the present invention, a customized contract is created based on the needs of 
the parties. Once created, the contract is stored within the secure computer infrastructure. 
Security within the computer infrastructure is typically provided through encryption such as 128 
bit encryption. Moreover, all actions taken with respect to the contract (e.g., approval, execution, 
etc.) occur within the infrastructure and are recorded based on time and date so that a record can 
be provided. Still yet, any party attempting to access the infrastructure to take action will first be 
authenticated before such access is granted. In order for the contract to be electronically 
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executed, both the originating contract partner and the receiving contract partner must first 
deliberately approve the contract. Once approval has been obtained, the contract can be 
electronically executed by both parties. After execution is complete, a final image of the contract 
can be generated that includes the electronic signatures and the date of execution. The present 
invention provides several key advantages over previous systems such as: security; 
confidentiality; data integrity; data retention; data access; authentication and repudiation 
prevention. 

[0038] In any event, as used herein, the term "contract" is intended to refer to any legally binding 
agreement, such as a joint development agreement, a license agreement, a service agreement, etc. 
To this extent, the term contract includes, but is not limited to agreements that have been 
negotiated between the parties where one party is performing a service and/or delivering 
hardware for the other, or delivering. Further, as used herein, the term "originating contract 
partner" is intended to refer to a party offering a contract to another party, while the term 
"receiving contract partner" is intended to refer to a party accepting/negotiating a contract from 
an "originating contract partner." 

[0039] Referring now to Fig. 1, a system 10 for electronically executing contracts within a secure 
computer infrastructure (infrastructure) 12 is shown. Infrastructure 12 is intended to represent 
any type of computer architecture that is maintained in a secure environment (i.e., for which 
access control is enforced). As shown, infrastructure 12 includes computer system 14 that 
typically represents a server or the like. It should be understood, however, that although not 
shown, other hardware and software components (e.g., additional computer systems, routers, 
firewalls, etc.) could be included in infrastructure 12. 
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[0040] In general, originating contract partner (OCP) 16 and receiving contract partner (RCP) 18 
will interface with infrastructure 12 to generate, approve and electronically execute a customized 
contract. To this extent, OCP 16 and RCP 18 could access infrastructure 12 directly, or over a 
network via interfaces (e.g., web browsers) loaded on computerized devices (e.g., personal 
computers, laptops, handheld devices, etc. not shown in Fig. 1). In the case of the latter, the 
network can be any type of network such as the Internet, a local area network (LAN), a wide area 
network (WAN), a virtual private network (VPN), etc. In any event, communication with 
infrastructure 12 could occur via a direct hardwired connection (e.g., serial port), or via an 
addressable connection that may utilize any combination of wireline and/or wireless transmission 
methods. Moreover, conventional network connectivity, such as Token Ring, Ethernet, WiFi or 
other conventional communications standards could be used. Still yet, connectivity could be 
provided by conventional TCP/IP sockets-based protocol. In this instance, OCP 16 and RCP 18 
could utilize an Internet service provider to establish connectivity to infrastructure 12. 
[0041] It should be understood that under the present invention, infrastructure 12 could be owned 
and/or operated by a party such as OCP 16, or by an independent entity. In the case of the 
former, OCP 16 would use infrastructure 12 to form contracts with outside parties such as RCP 
18. In the case of the latter, infrastructure 12 could be used independently by OCP 16 and RCP 
18 to form a contract. To this extent, infrastructure 12 could be offered to parties on a fee-basis. 
In either scenario, administrator 20 could support and configure infrastructure 12. 
[0042] Regardless, as further shown, computer system 14 generally comprises central processing 
unit (CPU) 22, memory 24, bus 26, input/output (I/O) interfaces 28, external devices/resources 
30 and storage unit 32. CPU 22 may comprise a single processing unit, or be distributed across 
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one or more processing units in one or more locations, e.g., on a client and computer system. 
Memory 24 may comprise any known type of data storage and/or transmission media, including 
magnetic media, optical media, random access memory (RAM), read-only memory (ROM), a 
data cache, etc. Moreover, similar to CPU 22, memory 24 may reside at a single physical 
location, comprising one or more types of data storage, or be distributed across a plurality of 
physical systems in various forms. 

[0043] I/O interfaces 28 may comprise any system for exchanging information to/from an 
external source. External devices/resources 30 may comprise any known type of external device, 
including speakers, a CRT, LCD screen, handheld device, keyboard, mouse, voice recognition 
system, speech output system, printer, monitor/display, facsimile, pager, etc. Bus 26 provides a 
communication link between each of the components in computer system 14 and likewise may 
comprise any known type of transmission link, including electrical, optical, wireless, etc. 
[0044] Storage unit 32 can be any system (e.g., database) capable of providing storage for 
information under the present invention. Such information could include, for example, contracts, 
activity histories, etc. As such, storage unit 32 could include one or more storage devices, such 
as a magnetic disk drive or an optical disk drive. In another embodiment, storage unit 32 
includes data distributed across, for example, a local area network (LAN), wide area network 
(WAN) or a storage area network (SAN) (not shown). Although not shown, additional 
components, such as cache memory, communication systems, system software, etc., may be 
incorporated into computer system 14. In addition, it should also be appreciated that although 
not shown, any computerized devices operated by OCP 16 and RCP 18 would likely include 
computerized components similar to computer system 14. 
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[0045] Shown in memory 24 of computer system 14 is contract system 34. Under the present 
invention, contract system 34 allows for the customized creation, approval and electronic 
execution of a contract within infrastructure 12. Specifically, as will be further described below, 
contract system 34 provides several key protocols/advantages not previously recognized. For 
example, under the present invention: (1) security is maintained (e.g., typically through 128 bit 
encryption); (2) confidentiality is maintained so that only appropriate parties can view data and 
contracts; (3) data integrity is maintained so that corruption does not occur; (4) data retention is 
provided so that the parties can later view the contract and its surrounding activity; (5) 
authentication is required so that only authorized parties can access the infrastructure 12 and 
pertinent contracts; (6) non-repudiation is provided by ensuring that the party executing the 
contract is the actual party and not a fraudulent user; and (7) data access is provided so that 
appropriate parties can view data relating to the contract process. 

[0046] Referring now to Fig. 2, contract system 34 is shown in greater detail. As depicted, 
contract system 34 includes registration system 36, authentication system 38, security system 40, 
activity tracking system 42, contract creation system 44, contract approval system 46, contract 
execution system 48 and image system 50. Each of these systems represents program code that 
performs the function described below. In performing these function, the systems within contract 
system 34 will likely generate any necessary interface pages and/or notifications that are used to 
electronically generate, approve and execute a contract under the present invention. 
[0047] The functions of each of these systems will be further described below, but in general, 
registration system 36 will be used to first register the parties. In the case where infrastructure 12 
is owned/operated by OCP 16, only registration of RCP 18 might be necessary. In general, 
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registration of a party entails obtaining profile information such as contact information. 
Registration is also used so that parties can be later authenticated when attempting to access 
infrastructure 12. In addition, once profile information is obtained, registration system 36 can 
communicate with other external systems (not shown) to perform a credit check or the like on a 
registering party. Authentication system 38 ensures that only authorized parties can access 
infrastructure 12. Typically this is done based on login information such as a user name and 
password. Security system 40 provides security for infrastructure 12 against hackers and the like. 
This is typically accomplished using 128 bit encryption or other similar method. Activity 
tracking system 42 is used to track all activity occurring within infrastructure 12 (e.g., based on 
date and time as well as an IP address of the users performing the actions). For example, when a 
contract is created, an entry will be made in storage unit 24 or the like. Similarly, as OCP 16 and 
RCP 18 approve and execute the contract, an entry will be made in storage unit 32. This allows a 
complete history of activity to be easily viewed. Contract creation system 44 will create a 
customized contract for OCP 16 and RCP 18 based on the needs thereof. Contract approval 
system 46 will coordinate the approval of the contract by OCP 16 and RCP 18. Once the 
contract is approved, contract execution system 48 will coordinate the execution of the contract 
by OCP 16 and RCP 18. After the contract is executed, image system 50 will generate a final 
image of the contract for the parties. 



II. DETAILED EXAMPLE 

[0048] The functions of the present invention will be further described below. For the remainder 
of this disclosure, assume as an illustrative example that infrastructure 12 is owned/operated by 
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OCP 16 from whom RCP 18 wishes to purchase a service contract. In this scenario, RCP 18 will 
first be registered as described above. As part of the registration process, an electronic 
notification (e.g., an e-mail) will be communicated to RCP 18. The electronic notification will 
likely include a link such as a URL, which upon selection by RCP 18, will provide initial access 
to infrastructure 12. Once this initial access is provided, authentication system 38 will provide 
RCP 18 with a user name and password (which can be changed by RCP 18) for subsequent 
access of infrastructure 12. 

[0049] After RCP 18 has been registered, OCP 16 will communicate therewith to obtain RCP 
18's contract requirements/information. For example, RCP 18 might be seeking a service 
contract covering certain pieces of hardware, for a certain length, and for a certain price. This 
contract information can be collected manually by OCP 16 (or a representative thereof), or 
electronically via e-mail or the like. In any event, the contract information can be populated into 
an interface page 60 such as shown in Fig. 3. From the information contained within interface 
page 60, a new contract can be customized. Specifically, using the contract information in 
interface page 60, contract creation system 44 (Fig. 2) will generate a new contract. Because the 
contract is based on the individual needs of the parties, it is considered to be a customized 
contract, as opposed to a boilerplate agreement such as a "click and accept" agreement. 
[0050] Once the contract has been created, activity tracking system 42 (Fig. 2) will log the 
generation of the contract based on date and time in storage unit 32. In addition, the contract will 
be assigned an initial status of "Submitted" (e.g., by contract creation system 44). Referring to 
Fig. 4, this is shown in greater detail. As depicted, Fig. 4 shows an interface page 70 depicting 
the status of three different contracts. The first contract (encircled) has been given the status of 
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"Submitted" meaning that is has been created but not yet approved. Fig. 4 shows three contracts 
to illustrate that a single party can use infrastructure and contract system 34 to reach multiple 
contracts at once. In this case, not all need be with the same opposing party. For example, 
assume that Fig. 4 shows the three contracts OCP 16 has with other parties. One contract could 
be the one pending with RCP 1 8, while the other two could be those pending with two other 
RCPs. To this extent, each party could have its own "room" within infrastructure 12 that 
contains all of its pending contracts. Only that party could have permission to access its room. 
This model could be extended to individuals or departments within a single organization. For 
example, each department could have its own room that cannot be accessed by other 
departments. 

[0051] Regardless, once the contract has been generated, contract approval system 46 (Fig. 2) 
will generate and send an electronic approval notification (e.g., e-mail) to OCP 16. Fig. 5 depicts 
an illustrative approval notification 80 for OCP 16. As depicted, approval notification 80 
includes a link 82. Upon selection of link 82, OCP 16 will be brought to a login page to log into 
infrastructure 12. Fig. 6 depicts an illustrative login page 90. As shown, login page 90 prompts 
OCP 16 for login information 92 such a user name and password. Upon being submitted, 
authentication system 38 will attempt to authenticate the information. If successful, contract 
approval system 46 (Fig. 2) will display an interface page for OCP 16 to approve the contract. 
To this extent, link 82 can be considered to be a "smart link" that sends OCP 16 directly to the 
contract to be approved once authentication is successful. 

[0052] Referring to Fig. 7, an illustrative such interface page 100 is shown. As depicted, 
interface page 100 not only includes biographical information 102 about the contract and activity 
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related thereto, but also a mechanism 104 for OCP 16 to input comments as well as to approve, 
deny (e.g., seek changes) or have the contract withdrawn completely. In approving the contract, 
it should be understood that one or more individuals within OCP 16 could be required to act in 
this manner. 

[0053] Once OCP 16 approves the contract, the status thereof will be changed to "New" by 
contract approval system 46 (Fig. 2) as demonstrated in interface page 1 10 of Fig. 8. Thereafter, 
contract approval system 46 (Fig. 2) will communicate an electronic approval notification to 
RCP 18. As shown in Fig. 9, approval notification 120 for RCP 18 is similar to approval 
notification 80 for OCP 16 of Fig. 5. In any event, upon selecting (smart) link 122 in approval 
notification 120, RCP will arrive at a login page 130 (Fig. 10) for inputting login information 
132. Once submitted, authentication system 38 (Fig. 2) will attempt to authenticate RCP 18's 
login information. If successful, the "smart" link 122 will bring RCP 18 directly to the contract 
for approval. To this extent, Fig. 1 1 shows an illustrative interface page 140 that RCP 18 will be 
presented for approving the contract. Similar to interface page 100 (Fig. 7) presented to OCP 16, 
interface page 140 contains biographical information 142 as well as a mechanism 144 for RCP 
18 to input comments and to indicate the contract is ready to sign, to reject the contract, or to 
request changes to the contract. 

[0054] If RCP 18 requests changes to the contract, RCP 18 will be provided with an interface 
page or the like to create an issue list that denotes RCP 18's objections to the contract. OCP 16 
can then create new version(s) of the contract based on the issue list. All versions of the contract 
as well as the surrounding activities will be maintained by the system. 
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[0055] Alternatively, if RCP 18 approves of the contract (indicates it is ready to sign), the status 
will be changed by contract approval system 46 (Fig. 2) to "Ready to Sign." In a typical 
embodiment, if RCP 18 indicates the contract is "Ready to Sign," any comments input by RCP 
18 can be blocked out. This helps prevent subsequent repudiation or dispute. In any event, Fig. 
12 depicts an interface page 150 showing this new status. At this point contract approval system 
48 (Fig. 2) can begin the process of having OCP 16 and RCP 18 execute the contract. In typical 
embodiment, RCP 18 will be solicited for execution first (although this need not be the case). 
Accordingly, Fig. 13 depicts an illustrative execution notification 160 that will be communicated 
to RCP 18. Similar to the approval notification, execution notification 160 includes a (smart) 
link 162, which upon selection by RCP 18, will direct RCP 18 to a login page (e.g., Fig. 10). 
Similar to the approval process, RCP 18's login information will first be authenticated. 
Thereafter, as shown in Fig. 14, RCP 18 will be presented with an interface page 170 for 
approving the contract. As depicted, interface page 170 includes biographical information 172 
and mechanism 176 to accept/execute the contract. Interface page 170 can also include a legal 
notice 174 or the like. 

[0056] Once RCP 18 executes the contract, contract execution system 48 (Fig. 2) will change the 
status thereof to "Signed," as indicated in the interface page 180 of Fig. 15. Then, execution by 
OCP 16 can be solicited in a similar manner. Specifically, an electronic execution notification 
190 (Fig. 16) will be communicated thereto. Similar to the approval notification, execution 
notification 190 can include a (smart) link 192 to a login page. Once the login information for 
OCP 16 has been authenticated, an interface page 200 such as that shown in Fig. 17 can be 
provided. As shown, interface page 200 includes biographical information 202 and a mechanism 
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204 for OCP 16 to accept/execute the contract or withdraw it completely. It should be noted that 
the execution pages 170 (Fig. 14) and 200 both include another prompt for RCP 18 and OCP 16 
to input login information. This provides yet another opportunity to authenticate each party and 
ensure that the individual making the selections is in fact authorized to do so. In any event, once 
OCP 16 has executed the contract, the status thereof will be changed by contract execution 
system 48 (Fig. 2) to "Countersigned" as shown in interface page 210 of Fig. 18. 
[0057] At this point, OCP 16 can be prompted by image system 50 (Fig. 2) via notification or the 
like to have a final image of the contract generated. To this extent, once OCP 16 logs in and is 
authenticated, an interface page such as 220 of Fig. 19 can be provided. As shown, interface 
page 220 include biographical information 222 as well as a mechanism 224 for OCP 16 to add 
the electronic signatures to the contract. Once this is done, a final image of the contract is 
generated. Referring to Fig. 20, an illustrative final image 230 is shown. As depicted, final 
image 230 includes the electronic signatures of OCP 16 and RCP 18 as well the corresponding 
date stamps of execution. At this point, as shown in the interface page 240 of Fig. 21, the status 
of the contract will be changed to "Complete." 

[0058] Because activity tracking system 42 (Fig. 2) recorded all activity surrounding the contract, 
either party can log into the system to view the details. For example, referring to Fig. 22, an 
illustrative interface page 250 for viewing the contract details is shown. Interface page 250 not 
only sets forth some biographical information 252, but also has a mechanism 254 for a party to 
view a document history of the contract, or an execution history of the contract. As indicated 
above, activity tracking system 42 could also track the IP addresses of OCP 16 and RCP 18 as 
the actions are performed. This also helps prevent repudiation by either party, 
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[0059] Because the present invention incorporates various safeguards, repudiation of the contract 
by either party is extremely difficult. For example, not only do approval and execution of the 
contract require separate deliberate actions by both parties, but authentication is also provided at 
all phases of the process, including twice for execution. Moreover, the present invention 
provides an opportunity for appropriate legal notices to be provided. 
[0060] It should also be understood that the present invention can be realized in hardware, 
software, or a combination of hardware and software. Any kind of computer system(s) - or other 
apparatus adapted for carrying out the methods described herein - is suited. A typical 
combination of hardware and software could be a general purpose computer system with a 
computer program that, when loaded and executed, carries out the respective methods described 
herein. Alternatively, a specific use computer, containing specialized hardware for carrying out 
one or more of the functional tasks of the invention, could be utilized. The present invention can 
also be embedded in a computer program product, which comprises all the respective features 
enabling the implementation of the methods described herein, and which - when loaded in a 
computer system - is able to carry out these methods. Computer program, software program, 
program, or software, in the present context mean any expression, in any language, code or 
notation, of a set of instructions intended to cause a system having an information processing 
capability to perform a particular function either directly or after either or both of the following: 
(a) conversion to another language, code or notation; and/or (b) reproduction in a different 
material form. 

[0061] The foregoing description of the preferred embodiments of this invention has been 
presented for purposes of illustration and description. It is not intended to be exhaustive or to 
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limit the invention to the precise form disclosed, and obviously, many modifications and 
variations are possible. Such modifications and variations that may be apparent to a person 
skilled in the art are intended to be included within the scope of this invention as defined by the 
accompanying claims. For example, the status of the contract could be changed by a "status 
system" (not shown) in contract system 34 instead of by the individual systems as described 
above. Moreover, although certain terminology has been used herein to indicate the various 
status's of the contract, it should be understood that other versions of terminology could be 
utilized. Still yet, although 128 bit encryption is indicated as the typical method of encryption, 
any other type of encryption could be implemented to provide security for the system. 
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